Hardened Memory Allocator for many Applications to increase Security

This page is archived.

Deprecation in Kicksecure

Context:

This context was added in November 2025.
The original rationale was written in February 2024.
Purpose of this explanation: To justify the integration or non-integration of hardened_malloc into Kicksecure (and Whonix), from the perspective of distribution development.

Reasons - written in February 2024:

Not stable enough: Through testing and integration development in Kicksecure, the unresolveable #Issues being found, it has been determined that it will never be stable enough to be suitable for installation by default for all users.
Unclear Benefit: See chapter #Tickets and Discussions. Whenever it has been suggested to other projects to port to Hardened Malloc (HM), it did not get favorable reviews from other developers.
Lack of outreach by upstream: Upstream mentioned that others do not understand HM but also does not have time to engage with them.
Potential future deprecation by upstream: Upstream contemplated deprecation of Hardened Malloc support for usage outside of a Android / GrapheneOS context.
Security issues? No. Users can keep using Hardened Malloc (Default) or Hardened Malloc Light until the next major release (Kicksecure version 18) but it will be unsupported.
Architecture support: Limited. (HM supports AMD64 architecture only, which makes Kicksecure progress towards multiple architecture support such as ARM64 and PPC harder.)
- Update November 2025: The original issue can no longer be identified, possibly due to Upstream Deleting Posts. It may have been similar to Build issue on Rocky Linux 9 aarch64 #228, a compilation issue that might have been resolvable in theory, but Kicksecure lacked the resources to maintain a fix at the time this was written. As of February 2024, HM offered no direct support for Debian. Pull request Debian packaging work in progress #90 received no feedback and was locked without explanation. This is entirely within the rights of the HM project, which has no obligation to support other Linux distributions. However, it is relevant context and has contributed to the deprecation of HM in Kicksecure, and is therefore included here.
Future: Is there any chance this package will get unarchived, maintained again in Kicksecure? No.
Forum discussion: https://forums.whonix.org/t/hardened-malloc-hardened-memory-allocator/7474/231

New reason - added November 2025:

Upstream is difficult to work with: Upstream has declined communication and issued bans.
- https://tech.michaelaltfield.net/2025/08/19/grapheneos-daniel-micay-banned/
- https://forums.kicksecure.com/t/grapheneos-attacks-kicksecure-what-should-the-response-be/739/6
- Upstream Deleting Posts
  - Upstream’s decision to disengage will be respected.
  - To clarify, no private communication has occurred.
  - All prior interactions have fortunately taken place in public.

NOINDEX

For context, wiki page Hardened Malloc uses wiki keyword NOINDEX. Quote Wikipedia:

The noindex value of an HTML robots meta tag requests that automated Internet bots avoid indexing a web page.Wikipedia article noindex

This is done deliberately to prevent the page from appearing in Google and other search engine results. The intention is to minimize drama. Discussion about hardened malloc is not a core activity of the project. Those interested in Kicksecure’s development and integration perspective can find the details; otherwise, the topic is considered sufficiently addressed.

Discussion

Introduction

Hardened Malloc (Default) is a hardened memory allocator which can be used with many applications to increase security.

This is a security-focused general purpose memory allocator providing the malloc API along with various extensions. It provides substantial hardening against heap corruption vulnerabilities. The security-focused design also leads to much less metadata overhead and memory waste from fragmentation than a more traditional allocator design. It aims to provide decent overall performance with a focus on long-term performance and memory usage rather than allocator micro-benchmarks. It offers scalability via a configurable number of entirely independently arenas, with the internal locking within arenas further divided up per size class.Daniel Micay, Hardened Malloc developer, founder and lead developer of GrapheneOS, hardened_malloc project page

Readers who wish to discuss the integration of Hardened Malloc with Kicksecure should refer to this forum thread.

Naming

The author of Hardened Malloc uses only the terms:

Hardened Malloc
Hardened Malloc Light

To distinguish better which version is used, this websites uses the terms:

Hardened Malloc (Default)
Hardened Malloc Light

This is unrelated to price. Both versions are Freedom Software, free as in price as well as in freedom.

Hardened Malloc Light is provided for cases in which Hardened Malloc (Default) cannot be used due to application specific issues. Hardened Malloc (Default) might trigger issues due to memory allocation bugs found in some applications.

Installation

Hardened Malloc (Default) is pre-installed.

How-to: Launch Applications with Hardened Malloc Default

Warning: This is for testers-only!

Launch Specific Applications with Hardened Malloc Default

To launch chosen applications with Hardened Malloc (Default), the LD_PRELOAD environment variable must be edited before starting the application.

For example, to launch application-name in this way, run.

LD_PRELOAD='libhardened_malloc.so' application-name

Using administrative rights, example:

sudo LD_PRELOAD='libhardened_malloc.so' apt update

Launch Systemd Services with Hardened Malloc Default

To launch individual systemd services with Hardened Malloc (Default), add a drop-in systemd configuration snippet.

Environment="LD_PRELOAD='libhardened_malloc.so'"

Launch All Applications by Default with Hardened Malloc Default

It is possible to make all applications use Hardened Malloc (Default) as the default memory allocator.

Note:

If using a graphical desktop environment (such as Xfce): This action breaks the graphical desktop environment (Xorg). Most users using a graphical desktop environment (such as Xfce) should not proceed enabling Hardened Malloc (Default) for all applications. Only Hardened Malloc Light is suitable for that.
If using a command line interface (CLI) (no graphical desktop environment) (such as a server): This can be attempted! Testers only!

To configure this option, the path to the hardened_malloc.so library must be added to the /etc/ld.so.preload file. ^[1]

1. Open file /etc/ld.so.preload in an editor with root rights.

Select your platform.

See Open File with Root Rights for detailed instructions on why using sudoedit improves security and how to use it.

Note: Mousepad (or the chosen text editor) must be closed before running the sudoedit command.

sudoedit /etc/ld.so.preload

Notes:

When using Kicksecure-Qubes, this must be done inside the Template.

sudoedit /etc/ld.so.preload

After applying this change, shut down the Template.
All App Qubes based on the Template need to be restarted if they were already running.
This is a general procedure required for Qubes and is unspecific to Kicksecure-Qubes.

Notes:

This is just an example. Other tools could achieve the same goal.
If this example does not work for you, or if you are not using Kicksecure, please refer to Open File with Root Rights.

sudoedit /etc/ld.so.preload

2. Add the hardened_malloc.so library.

Paste.

libhardened_malloc.so

3. Save the file.

4. Done.

The procedure is complete. Hardened Malloc Default has been enabled for all applications by default.

Disable Hardened Malloc per Application

In case Hardened Malloc Default/Light is enabled globally for all applications it is possible to disable it for select applications should that be required due to application incompatibilities.

Apply the following steps to disable Hardened Malloc Default/Light per application.

Prepend the ld-system-preload-disable wrapper.

Syntax:

ld-system-preload-disable application

Example:

Notes:

This disabled all ld system preload. This only matters in case the user previously modified ld system preload configuration file /etc/ld.so.preload which the vast majority of users do not do.
Replace chromium with the actual application which should be started without ld system preload.

ld-system-preload-disable chromium

Issues

Incompatible Applications

Graphical Desktop Environment Xorg

	Hardened Malloc (Default)	Hardened Malloc Light
Kicksecure on the host	Yes, functional.	Yes, functional.
Kicksecure inside VirtualBox Xfce	No, Xorg broken.	Yes, functional.
Kicksecure inside VirtualBox CLI	Yes, functional. (Not using Xorg.)	Yes, functional. (Not using Xorg.)
Kicksecure inside KVM	Yes, functional.	Yes, functional.
Kicksecure for Qubes	Yes, functional. (Not using Xorg.)	Yes, functional. (Not using Xorg.)

TODO:

Xorg systemd drop in InaccessiblePaths=-/etc/ld.so.preload
port to Wayland

VirtualBox Host Software

A) Hardened Malloc on the host: VirtualBox crashes with hardened memory allocator Hardened Malloc on the host. ^[2]
B) Hardened Malloc inside a VM: However, using HM inside VirtualBox VMs is different. For that, see above wiki chapter.

Browsers

Firefox

Using Hardened Malloc Default/Light with Firefox is broken and unsupported. ^[3]

To start Firefox without Hardened Malloc, run.

ld-system-preload-disable firefox-esr

Tor Browser

Using Hardened Malloc Default/Light with Tor Browser is also is broken and unsupported. Same as above. This is because Tor Browser is based on Firefox. ^[4]

To start Tor Browser without Hardened Malloc:
- Note: Adjust path Tor Browser's startup script start-tor-browser if you are using a different Tor Browser installation folder.
- ld-system-preload-disable ~/.tb/tor-browser/Browser/start-tor-browser
If using Tor Browser Starter (package: tb-starter) by Whonix developers:
- ld-system-preload-disable torbrowser

Chromium

Using Hardened Malloc Default/Light with Chromium is also is broken and unsupported. ^[5]

To start Tor Browser without Hardened Malloc, run.

ld-system-preload-disable chromium

Other Browsers

It is unknown whether other browsers can benefit from Hardened Malloc Default/Light.

Flatpak

Flatpak does not honor /etc/ld.so.preload. Therefore using Hardened Malloc with Flatpak applications is currently unsupported. ^[6]

Bug: Hardened Malloc Ignored by Flatpaks

snap

snap is untested. Possibly has the same issue as Flatpak.

php

php command from php8.2-cli php package segfaults.

php

zsh: segmentation fault (core dumped)  php

To start PHP on the command line without Hardened Malloc, run.

ld-system-preload-disable php

If PHP is started by other applications such as a web server, it is currently untested if that is broken.

Others

Other applications might not easily benefit from Hardened Malloc Default/Light for the same reasons outlined in the browsers section above.

Whether an application can benefit from Hardened Malloc Default/Light or not depends on technical implementation details of the application in question. Vendors of applications will probably know if their application is compatible with Hardened Malloc Default/Light. Community wiki contributions are most welcome -- please post any additional vendor Q&As here.

workaround available

Slowdown of swap-file-creator at shutdown.

related to above cryptsetup slowdown by factor ~ 7
workaround OK Kicksecure GitHub swap-file-creator repository subpath

no workaround available

major issues:

cryptsetup slowdown by factor ~ 6
- reported upstream: cryptsetup luksFormat slowdown of factor ~ 6 when using hardened memory allocator Hardened Malloc

minor issues:

Qubes issues (when using Debian based VMs inside Qubes OS):
- Installing Hardened Malloc and enforce enabling it will lead to duplication in Copy to VM & Move to VM
- Memory issue founded by Hardened-Malloc - "icon-sender: segfault at ... libc-2.31.so"
element bug report: Memory issues detected by hardened malloc - libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)

Development Notes

Tickets and Discussions

chromium feature request: consider using hardened malloc
- No favorable review by Chromium developers.
  - This is probably made unnecessary by the PartitionAlloc work, which contains similar security features. See https://source.chromium.org/chromium/chromium/src/+/main:base/allocator/partition_allocator/PartitionAlloc.md.
tor-dev mailing list: TBB Memory Allocator choice fingerprint implications
- tor-dev mailing list thread TBB Memory Allocator choice fingerprint implication
- The thread did not go well.
Tor Browser feature request: consider using Hardened Malloc for better security in TBB - got closed probably due to the outcome of above mailing list discussion.
glibc feature request: consider using Hardened Malloc

Related Feature Requests Improving Integration Work

These are not caused by hardened malloc but instead are feature requests for other upstream projects which would ease integration.

glibc feature request: /etc/ld.so.preload.d drop-in configuration folder support
glibc feature request: LD_ETC_IGNORE - environment variable to ignore /etc/ld.so.preload configuration file on a per-application basis
Debian request for packaging: RFP: hardened-malloc -- hardened memory allocator
Qubes feature request: Hardened Malloc For Qubes OpenQA
Debian glibc feature request: consider using hardened malloc (hardened memory allocator)

Upstream Considerations of Hardened Malloc Deprecation for x86

Context:

This context was added November 2025.
Original was written in February 2024.
Original source not archived. And not worthwhile to investigate further. Hence, ~~strike-through~~ formatting will be used.

Perhaps we'll give up on the partial support for using hardened_malloc outside of an Android-based OS, particularly since people don't seem to understand the difference between it and simply bolting on some hardening features to a traditional allocator design, I've already had the usual experience today.quote ~~Hardened Malloc upstream developer Daniel Micay, @thestinger~~

There are many examples of imported public statements which are deleted by upstream but still available on the Web Archive.

Upstream Deleting Posts

Certain statements were made and later deleted, making meaningful cooperation difficult.

Michael Altfield was banned from the GrapheneOS project by Daniel Micay after submitting a feature request and reopening a previously deleted issue. No specific misconduct was identified, and Daniel Micay subsequently deleted his own comments and declined to explain the rationale behind the ban, leaving Michael Altfield uncertain about the reason. For further context, refer to the blog post: Why I was banned from GrapheneOS by Daniel Micay
Below are examples of posts that were later removed.

Original Link (defunct nowadays)	Archived Link
https://github.com/thestinger/daniel.micay.dev/commit/79e44b41190cd5c64c4ccd9fec4301ee6008da53	https://web.archive.org/web/20230526182001/https://github.com/thestinger/daniel.micay.dev/commit/79e44b41190cd5c64c4ccd9fec4301ee6008da53
https://twitter.com/DanielMicay/status/1662212227561308160	https://web.archive.org/web/20230526232932/https://twitter.com/DanielMicay/status/1662212227561308160
https://nitter.net/DanielMicay/status/1662212227561308160	https://web.archive.org/web/20230526221745/https://nitter.net/DanielMicay/status/1662212227561308160
https://github.com/GrapheneOS/hardened_malloc/issues/84	https://web.archive.org/web/20220416101153/https://github.com/GrapheneOS/hardened_malloc/issues/84 https://archive.ph/hHFxE
https://github.com/GrapheneOS/hardened_malloc/issues/86	https://web.archive.org/web/20240905204810/https://github.com/GrapheneOS/hardened_malloc/issues/86 https://archive.ph/ZmYc9

Why does this wiki chapter, "Upstream Deleting Posts", exist? It originates from a public Qubes forum discussion that references Deprecation in Kicksecure. Statements cited in the "Deprecation in Kicksecure" section linked to posts that were subsequently deleted. This chapter provides evidence that upstream has a history of deleting links.

How-to: Check Hardened Malloc Status

Check If Hardened Malloc is Enabled

Open the terminal and type either:

A): Using hardened-malloc-enabled-test. hardened-malloc-enabled-test
- If enabled, should output should show:
  yes
B): For advanced users: Using systemcheck with command line parameter --verbose. systemcheck --verbose
- If enabled, should output should include:
  [INFO] [systemcheck] Hardened Malloc: Hardened Malloc enabled.

Check If Hardened Malloc Default or Hardened Malloc Light is Enabled

hardened-malloc-type-test

Possible outputs:

none
default
light

Kicksecure Feature Default Status Information

(A) blocker, reason why Hardened Malloc is not enabled by default in Kicksecure yet is because it breaks browsers, which would be confusing.

Past Contributions

Credits and Source Code

The Hardened Malloc upstream source code is maintained by security researcher, Daniel Micay.

This website is the software fork homepage for Hardened Malloc, with a focus on easy installation, added user documentation, and integration with Kicksecure, Whonix^®, Debian, and other distributions. The Kicksecure software fork source code can be found here.

Footnotes

↑ glibc feature request: /etc/ld.so.preload.d drop-in configuration folder support
↑
- https://www.virtualbox.org/wiki/VBoxMainLogging
- https://www.virtualbox.org/wiki/Core_dump
↑
Tor Browser is also based on Firefox, therefore the following information equally applies to both, Tor Browser and Firefox.

LD_PRELOAD='/path/to/libhardened_malloc.so' /path/to/program will do nothing or approximately nothing.

The reason is recompilation is necessary.
To successfully replace Firefox memory allocator you should either use LD_PRELOAD _with_ a --disable-jemalloc build OR Firefox's replace_malloc functionality: https://searchfox.org/mozilla-central/source/memory/build/replace_malloc.h
Sources:
- https://lists.torproject.org/pipermail/tor-dev/2019-August/013982.html
- https://lists.torproject.org/pipermail/tor-dev/2019-August/013990.html
↑
- https://forums.whonix.org/t/hardened-malloc-hardened-memory-allocator/7474/202
- https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42104
↑
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971876
  - workaround ld-system-preload-disable chromium ok
  - chromium from flathub also functional (Hardened Malloc Light is disregarded inside flatpak's bubblewrap based sandbox)
crosvm functions only if an option is specified at compile time
- CrosVM ships with strict Seccomp policies that block syscalls not typically generated by CrosVM.
- The hardened_malloc library generates calls a syscall for a random number generator, which will be blocked silently.
- Append string getrandom: 1 to jail/seccomp/x86_64/common_device.policy, which permits the RNG syscall for all CrosVM devices.
- Other getrandom: 1 entries must be removed from files in jail/seccomp/x86_64/*, as CrosVM will not compile with duplicate entries for devices.
- Without this addition: if too much data is buffered at once by the serial console or NIC, the device subprocess will crash, and thus the rest of the virtual machine.
- Without this addition, errors regarding seccomp violations for nr_random syscalls are detected in strace.Anonymously contributed wiki edit.
↑
Flatpak does not honor /etc/ld.so.preload. Viewing contents of /etc/ld.so.preload on the host operating system. cat /etc/ld.so.preload Expected output:
```
libhardened_malloc-light.so
```
Starting a shell inside a Flatpak application sandbox. This example uses org.chromium.Chromium and could be replaced with any other Flatpak application.
flatpak run --command=sh org.chromium.Chromium
Viewing contents of /etc/ld.so.preload inside the Flatpak sandbox.
cat /etc/ld.so.preload
Conclusion: File /etc/ld.so.preload does not exist inside the Flatpak sandbox.
```
cat: /etc/ld.so.preload: No such file or directory
```

Kicksecure

A secure by default operating system with the latest security research in place.

Dark mode

Supported by Power Up Privacy

Kicksecure is proudly supported until 2026 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

2012- 2025 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 13 year success story and maybe DONATE!

[1] glibc feature request: /etc/ld.so.preload.d drop-in configuration folder support

[2] 
https://www.virtualbox.org/wiki/VBoxMainLogging

https://www.virtualbox.org/wiki/Core_dump

[3] ttps://www.virtualbox.org/wiki/VBoxMainLogging

[4] ttps://www.virtualbox.org/wiki/Core_dump

[firefox-based-3] Tor Browser is also based on Firefox, therefore the following information equally applies to both, Tor Browser and Firefox.

LD_PRELOAD='/path/to/libhardened_malloc.so' /path/to/program will do nothing or approximately nothing.

The reason is recompilation is necessary.

To successfully replace Firefox memory allocator you should either use LD_PRELOAD _with_ a --disable-jemalloc build OR Firefox's replace_malloc functionality: https://searchfox.org/mozilla-central/source/memory/build/replace_malloc.h
Sources:

https://lists.torproject.org/pipermail/tor-dev/2019-August/013982.html

https://lists.torproject.org/pipermail/tor-dev/2019-August/013990.html

[6] ttps://lists.torproject.org/pipermail/tor-dev/2019-August/013982.html

[7] ttps://lists.torproject.org/pipermail/tor-dev/2019-August/013990.html

[4] 
https://forums.whonix.org/t/hardened-malloc-hardened-memory-allocator/7474/202

https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42104

[9] ttps://forums.whonix.org/t/hardened-malloc-hardened-memory-allocator/7474/202

[10] ttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42104

[5] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971876
workaround ld-system-preload-disable chromium ok

chromium from flathub also functional (Hardened Malloc Light is disregarded inside flatpak's bubblewrap based sandbox)

crosvm functions only if an option is specified at compile time
CrosVM ships with strict Seccomp policies that block syscalls not typically generated by CrosVM.

The hardened_malloc library generates calls a syscall for a random number generator, which will be blocked silently.

Append string getrandom: 1 to jail/seccomp/x86_64/common_device.policy, which permits the RNG syscall for all CrosVM devices.

Other getrandom: 1 entries must be removed from files in jail/seccomp/x86_64/*, as CrosVM will not compile with duplicate entries for devices.

Without this addition: if too much data is buffered at once by the serial console or NIC, the device subprocess will crash, and thus the rest of the virtual machine.

Without this addition, errors regarding seccomp violations for nr_random syscalls are detected in strace.Anonymously contributed wiki edit.

[12] ttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971876
workaround ld-system-preload-disable chromium ok

chromium from flathub also functional (Hardened Malloc Light is disregarded inside flatpak's bubblewrap based sandbox)

[13] workaround ld-system-preload-disable chromium ok

[14] romium from flathub also functional (Hardened Malloc Light is disregarded inside flatpak's bubblewrap based sandbox)

[15] CrosVM ships with strict Seccomp policies that block syscalls not typically generated by CrosVM.

[16] The hardened_malloc library generates calls a syscall for a random number generator, which will be blocked silently.

[17] Append string getrandom: 1 to jail/seccomp/x86_64/common_device.policy, which permits the RNG syscall for all CrosVM devices.

[18] Other getrandom: 1 entries must be removed from files in jail/seccomp/x86_64/*, as CrosVM will not compile with duplicate entries for devices.

[19] Without this addition: if too much data is buffered at once by the serial console or NIC, the device subprocess will crash, and thus the rest of the virtual machine.

[20] Without this addition, errors regarding seccomp violations for nr_random syscalls are detected in strace.Anonymously contributed wiki edit.

[6] Flatpak does not honor /etc/ld.so.preload. Viewing contents of /etc/ld.so.preload on the host operating system. cat /etc/ld.so.preload Expected output:
libhardened_malloc-light.so

Starting a shell inside a Flatpak application sandbox. This example uses org.chromium.Chromium and could be replaced with any other Flatpak application.
flatpak run --command=sh org.chromium.Chromium
Viewing contents of /etc/ld.so.preload inside the Flatpak sandbox.
cat /etc/ld.so.preload
Conclusion: File /etc/ld.so.preload does not exist inside the Flatpak sandbox.

cat: /etc/ld.so.preload: No such file or directory

[1]

[2]

[3]

[4]

[5]

[6]

Hardened Malloc (Default)

Deprecation in Kicksecure

NOINDEX

Discussion

Introduction

Naming

Installation

How-to: Launch Applications with Hardened Malloc Default

Launch Specific Applications with Hardened Malloc Default

Launch Systemd Services with Hardened Malloc Default

Launch All Applications by Default with Hardened Malloc Default

Kicksecure

Kicksecure-Qubes

Others and Alternatives

Disable Hardened Malloc per Application

Issues

Incompatible Applications

Graphical Desktop Environment Xorg

VirtualBox Host Software

Browsers

Firefox

Tor Browser

Chromium

Other Browsers

Flatpak

snap

php

Others

workaround available

no workaround available

Development Notes

Tickets and Discussions

Related Feature Requests Improving Integration Work

Upstream Considerations of Hardened Malloc Deprecation for x86

Upstream Deleting Posts

How-to: Check Hardened Malloc Status

Check If Hardened Malloc is Enabled

Check If Hardened Malloc Default or Hardened Malloc Light is Enabled

Kicksecure Feature Default Status Information

Past Contributions

Credits and Source Code

Footnotes

Navigation menu

Search